根据敏捷联盟现任董事会的说法，敏捷方法已经“跨越鸿沟”，我认为这意味着它们正变得越来越普及。虽然这有其优势，但也带来了问题。当一种方法论或设计方法变得流行时，我们会看到很多人在使用它或教授它，他们关注的是时尚而不是真正的细节。这可能会导致以敏捷的名义完成的事情与运动创始人的原则截然相反。

敏捷软件开发打破了需求分析、测试和开发之间的一些障碍。部署、运营和维护是其他活动，它们与软件开发过程的其他部分也存在类似的分离。DevOps 运动旨在消除这些障碍，并鼓励开发和运营之间的协作。

几年前，我与一位客户交谈，他告诉我他不喜欢我们正在使用的敏捷方法的一点：“在项目早期就遇到这些困难，感觉不对劲”。与他的反应相反，在我看来，这种早期的痛苦是敏捷或任何迭代开发过程的巨大*优势*之一。

极限编程 (XP) 是一种主要由Kent Beck开发的软件开发方法。XP 是最早的敏捷方法之一，事实上，在 Scrum 在 21 世纪 00 年代后期成为主流之前，XP 是 90 年代后期和 21 世纪 00 年代早期的主流敏捷方法。许多人（包括我自己）认为 XP 是让人们关注敏捷方法的主要催化剂，并且作为开始敏捷开发的基础，它优于 Scrum。

许多人认为你不能在敏捷项目中签订固定价格合同。由于敏捷过程的重点是你无法预测未来，因此这并非不合理的假设。然而，这并不意味着你不能提出一个固定价格的敏捷合同，它真正的含义是你不能提出一个固定范围的合同。

最近我听到不少项目都出现了一种混乱。情况是这样的

• 他们想使用敏捷流程，并选择了 Scrum
• 他们采用了 Scrum 实践，甚至可能是原则
• 一段时间后，由于代码库一团糟，进度缓慢

如果你关心你所做的事情，你就会关心如何做得更好。这包括反思你是如何做事的，并尝试新的技术，看看它们是否能让你做得更好。即使其他人推荐了新的技术，你唯一能知道它们是否适合你的方法就是自己尝试，看看它们是否能提高你的表现。

普通开发人员可以使用敏捷方法吗？

一个常见的问题是，大型项目是否可以使用敏捷技术来完成。毕竟，许多敏捷方法都是为较小的项目设计的，而它们所抵制的重量级想法在更大的项目中更需要。

成熟度模型是一种工具，可以帮助人们评估个人或团队当前的效率，并支持确定他们接下来需要获得哪些能力才能提高绩效。在许多圈子里，成熟度模型的名声很差，但尽管它们很容易被误用，但在正确的人手中，它们还是很有帮助的。

赞助软件开发的人通常对开发指标（如速度或部署到生产环境的频率）不太感兴趣。他们更关心软件将带来的业务效益，如减少人工、提高销售转化率、提高客户满意度，即业务成果。以结果为导向的团队是指那些被授权和配备了实现业务成果的团队，这些团队中的人员有能力执行实现成果所需的所有活动。相比之下，以活动为导向的团队既没有能力也没有被授权这样做。他们只能执行实现成果所需的几项活动中的一项。

我习惯于创造新词来描述我在软件开发中看到的东西。这在该领域的作家中很常见，因为软件开发仍然缺乏很多有用的术语。构建术语的一个问题是，术语很容易失去其含义，在一个语义扩散的过程中——用另一个可能添加到我们术语中的词来说。

在我最近的代码所有权帖子中，我描述了我对代码所有权问题的看法。我的许多软件开发朋友都是极限编程的拥护者，他们倾向于集体代码所有权。然而，这类实践并非绝对的，应该始终根据当地情况进行调整。我的一位同事给我发了一封邮件，里面讲述了以下故事，我认为这很好地说明了什么时候你必须改变你的实践，即使你是 XP 的忠实粉丝。（由于他在谈论他的团队，所以他希望保持匿名。）

守破离是一种思考如何学习一项技术的思维方式。这个名字来源于日本武术（特别是合气道），Alistair Cockburn将其引入，作为一种思考学习软件开发技术和方法的方式。

人们时常会质疑某个特定专业是否可以使用增量的方式：“你不能在敏捷项目中做（安全 | 用户界面设计 | 数据库 | 国际化 | * ），因为这方面必须预先完成。”

你在敏捷项目中常见的一件事是，开发团队坐在一个开放式的团队房间里。它在极限编程的早期就被提倡，并在第二版中被列为主要实践之一。敏捷主义者喜欢开放式的团队房间，因为它可以促进团队成员之间大量非正式和深入的沟通。

在我的职业生涯中，我一直看到的一个主题是软件开发的性质和重要性。几年前，一位潜在客户告诉我们的一位销售人员，“软件就像污水管道，我希望它能可靠地工作，我不想知道细节”。这就是 Nicholas Carr 在IT 不重要中谈到的那种方法。相比之下，我们为许多企业做过工作，在这些企业中，IT 显然是其业务的战略推动者，使它们能够进入新市场或显著提高市场份额。那么，IT 到底是像污水管道一样的公用事业，还是一种战略资产？